Loading...
 

Transactions (abort)

Examples for resetting certain system statuses when a database transaction is aborted

In the following examples, AbortTXN stands for both the InstantView® statement AbortTXN, for the termination of processing using the cancel statement or due to an error that has occurred.

Var(x, coll)

1 -> x
CreatePersObject(CX_ITEM)    // Txn startet hier
-> x
. . .
AbortTXN

The persistent object CX_ITEM no longer exists (ObjectStore takes care of this), and it would be fatal if x would refer to this object. Therefore the variable x is reset to the value 1 by the ClassiX® system.

1 -> x
"uniqueID = \"E0025\"" FindFirst(CX_ITEM)    // Txn startet hier
-> x
.  .  .
AbortTXN

The found object still exists, of course, but here too, x is reset to the value 1.

CreatePersCollection -> coll
EndTXN                            // dies geschieht in einer anderen Transaktion
.  .  .
CreatePersObject(CX_ITEM)         // die uns interessierende Txn startet hier
coll Insert
AbortTXN

The object just created no longer exists, and the persistent collection does not contain a reference to this object. The undoing of these actions is done exclusively by the rollback of the ObjectStore database.

CreateTransCollection -> coll
.  .  .
CreatePersObject(CX_ITEM)         // Txn startet hier
coll Insert
AbortTXN

The transaction mechanism of ObjectStore only refers to persistent data. The transient collection would continue to refer to the no longer existing object. This would be a contradiction to the behaviour of persistent collections and also grossly wrong! Therefore, the ClassiX® system resets all transient collections that have been changed within the just aborted transaction to the state at the beginning of the transaction.

CreateTransObject(CX_UNIT_PARAMETER) -> x
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
x Put
AbortTXN

The transient object is not changed by the abort of the transaction!

In contrast to transient collections, the changes of transient objects are not transactional.

Although a rollback of changes of transient objects in case of transaction abort would be desirable, this was not implemented in the ClassiX® system due to the high effort involved.
One can paraphrase examples with transient objects in such a way that a variable only refers to the transient object if the transaction is successfully completed:

NULL -> x
.  .  .
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
CreateTransObject(CX_UNIT_PARAMETER) -> x
x Put
AbortTXN

Because of the failed transaction, variable x does not hold the transient CX_UNIT_PARAMETER object, and this "free" object will be automatically removed from the garbage collection in the near future. 

[ 1 ] -> x           // ein Vektor
"zweites Element" x Insert

.  .  .
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
x Insert                             // ein weiteres Element
AbortTXN

When the transaction is aborted, the vector again consists only of the first two elements.

So far there is an analogy to transient collections. 

[ 1 ] -> x           // ein Vektor
"zweites Element" x Insert
0 FindAll(CX_UNIT_PARAMETER)        
x Insert                            
EndTXN
.  .  .
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
x Remove
AbortTXN

After Remove the vector is not reset. This is conceptually wrong.
This bug will be fixed in one of the next ClassiX® versions!